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<<V7> Abstract- The present invention relates to a method and arrangement in a communications network. The object or the present 
^ nvention is to provide a way of handling recourse management issues and admission control within anIP telephony system . The ob- 
° ecHs achieved by a topology aware resource manager collecting routing information concerning the IP network, obtaini ng resource 
O nformlion concerning resources within the IP network, creating a resource map by means of comb.ng satd touting mlormat.on 
^ andreiurce information, and performing recourse management issues and admission control wtthin the system by means o. sard 
^ resource map and by interacting with a gatekeeper. 
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METHOD FOR, AND A TOPOLOGY AWARE RESOURCE MANAGER IN AN 
IP-TELEPHONY SYSTEM 

5 The present invention relates to a method and arrangement in a communications 
network in accordance with the preambles of the independent claims. More 
specifically it relates to IP telephony recourse management issues and admission 
control within an IP telephony system. 

10 

BACKGROUND OF THE INVENTION 

Telephony is one of the most important inventions in mankind. Since its birth March 
10:th, 1876, installing copper wires to each and everyone that needed communication 

15 capabilities has spread the technology worldwide. By coupling copper wires together 
between caller and called, a connection between these was achieved and they could 
eventually communicate with each other through their circuit. This kind of technology 
has become known as circuit-switched telephony. Anyone familiar with classical 
telephony know that there has been a great evolution within this circuit-switched 

20 telephony with, for instance, the AXE platform the Ericsson Corporation developed 
as their switching solutions. Knowledge about statistical multiplexing of calls within 
the networks has made it possible to build networks with worldwide coverage to 
limited costs. 

25 During the last decade, die classical circuit- switched telephony service has met a 
competitor in the more cost efficient packet-switched telephony built upon the 
Internet protocol suite Transport Control Protocol /Internet Protocol (TCP)/ (IP). 
This telephony is usually referred to as IP telephony, which currently is being 
standardized and frequently installed instead of die old circuit-switched telephony. 
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The packet- switch IP telephony networks are commonly routed using one of the well- 
known IP routing protocols such as OSPF (Moy J., OSPF Version 2, IETF , 
RFC2328), IS-IS (Oran D., OSUS-IS Intra-domain Routing Protocol, IETF, RFC1142) or 
5 RIP (Malkin G-, RIP Version 2, IETF, RFC2453). These protocols can be classified 
either as being link-state or distance vector protocols based on the algorithms they 
use for route computation and distribution of routing information. All routers running 
a link state protocol within a domain have a complete view of the network, knowing 
all die networks and routers within the domain. A distance vector router knows only 
10 the routers and networks in its immediate surrounding (directly connected). 

Most commercial IP telephony systems follow the International Telecommunication 
Union - Telephony (ITU-T) Recommendation H.323. This recommendation was early 
adopted by major IP telephony vendors in their systems solutions. In Figure 1, an 

1 5 overview of the major components in an H.323 system is shown. 

These major components are terminals T, gateways G, and gatekeepers Gk. The three 
first components are referred to as endpoints of the H.323 system since these can 
initiate or terminate media streams. The gatekeeper is the manager of the H.323 
system. The managing domain is referred to as a zone. There is one, and only one, 

2 0 gatekeeper available in each zone. 

Terminals 

Terminals T are endpoints that provide real-time two-way communications, i.e. it is 
possible to talk and listen to another H.323 terminal T or another telecommunications 

25 system via a gateway. It can also participate in a multipoint conference through the 
MCU, which will be introduced below. An H.323 terminal T must support the -voice 
service. Besides the voice service, the terminal T can also provide video and data 
services, but these are optional. To be able to negotiate channel usage and do 
capability exchange between end-points, the terminal T must also support H.245. 

30 Other required components are call setup and signalling via Q.931, 
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registration/adtnission/status (RAS) for gatekeeper communication, and RTP/RTCP 
for transportation of real-time services, e.g. voice and video. 

Besides these required components, the terminal T could also have MCU capabilities. 
5 Gateway 

A gateway G is an interface between an H.323 system and another telecommunication 
systems, e.g. PSTN. The gateway G is optional and is only required when an endpoint 
communicates xvith other terminal types 102, e.g. ISDN, PSTN etc. The gateway G 
handles both the call control and the call transportation translation between the H.323 
1 0 system and the non-H.323 system. 

Multipoint control units 

The multipoint control units (MCU) support conferences between three or more 
endpoints. The MCU comprises a mandatory multipoint controller (MC) and 
15 optionally one or more multipoint processors (MP). The MC can be co-located Nvith 
another end-point, e.g. in a terminal. The MC handles negotiations between terminals 
during audio and video capability exchange. The MC also determines if any of the 
related media streams should be distributed with multicast. In case mixing of media 
streams are required, the MP handles this. As depicted in Figure 2, Multipoint 
2 0 communication can be made either in a centralised or a decentralised manner. In 
centralised multipoint conferencing, all communication between endpoints E is made 
via the MC. In the MC, the media streams are mixed together and distributed to 
involved endpoints E. In decentralised multipoint conferencing, the MC handles the 
negotiations while the endpoints E them self distributes the media streams. This 
25 distribution can be made with the resource efficient technology multicast. A mesh of 
unicast media distribution can also be used. Besides the centralised and the 
decentralised distribution method, hybrids between these are possible. 

Gatekeeper 
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The gatekeeper Gk is the most important component of an H.323 enabled network. It 
performs two important call control functions; address translation and bandwidth 
management. Address translation means that the gatekeeper Gk translates from aliases 
for terminals and gateways to IP addresses. The bandwidth management 
5 implementation is vendor specific. A commonly used method is to specify a threshold 
for the number of simultaneous calls that can be made within the zone the gatekeeper 
Gk manages. Other methods might exist but these are in that case vendor specific. 
Calls can be made directly between endpoints or via the gatekeeper Gk. The latter is 
referred to as gatekeeper-routed calls. 
10 Even though H.323 primarily was developed for non-guaranteed quality of service 
networks, the recommendation has been expanded to cover Quality of Sendee (QoS) 
issues as well. For instance, QoS Support for H.323 using RSVTP is discussed in 
appendix II of ITU-T Recommendation H.323 version 2, Packet-based multimedia 
com??2unication systems, Geneva, 1997. 

15 

Lack of topology awareness and path sensitive admission control is the most 
important drawback of current implementations of H.323 gatekeepers. In Figure 3, a 
topology for an H.323 enabled network 300 is shown. In the network there are three 
edge routers ER, one gatekeeper Gk and one gateway G to PSTN. In this network the 

20 routers R that connects LAN segments are geographically distributed, e.g. Stockholm, 
Gothenburg, Malmo, etc. Between these geographically distributed routers R the 
bandwiddi is limited. The gatekeeper Gk manages the whole network which then 
defines a zone. The gatekeeper Gk and the gateway G are geographically located 
where the number of users is highest. The gatekeeper Gk could be located anywhere, 

25 but for practical reasons these are co-located. The logical location for the gateway G is 
to place it where most of the calls are made. This will result in less routing of calls 
through the rest of the network, which would be the case if die gateway G were 
located in a LAN segment far away from the majority of the users. 

The gatekeeper Gk can be configured to allow X simultaneous calls on a heuuristic 
30 basis. If the perceived quality is degraded, the threshold of simultaneous calls can be 
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10 



deceased. This heuristic decision base will cause prob-ems. One taser can, wath or 
wtthout maliciotas .mentions, cause .ow overa.1 utiusation and denial of secvtce to 
other users. By staring seasons .hat use a dun bottleneck unit, the heunsncs wall be 
adiusred to allow very few sessions in the zone. Other users that are connected wrth 
well-provisioned links wi.1 then be denied access, even if the bottleneck link would not 
be involved in those sess.ons. Other problems will occur when the rasage bebavtour as 
changed in sonae way, or when there are topo.ogy change, Changed user behaviour 
could be drat rxrote users than usuaEy gets dreir calls roured over a that, or loaded hA 
which could cause packer drops or increased delays. Topology change cou,d be caused 
by Unk failure. Thts causes reroudng of packers meaning rhar the packets men take 
aherna.e paths through .he network. Topology change can also bo that a ^ larak 
characrensuc is changed in some way, e.g. mcreased or decreased bandwtdth, delay, 



15 



etc. 



20 



25 



Another problem is that garekeeper-roured cans cannot be guaranteed high servrcc 
pua Uty in case Career calls are allowed. If a gatekeeper Gk performs bandwtdth 
naanagement for garekeeper-routed caUs in a acne and is unaware of sknulraraeous 
direct cans the total traffic volume may exceed available bandwidth a, some link. The 
problem here is mar both gatekeeper-roured and direct calls use the same resources. 
This is due to that the gatekeeper Gk performs bandwidth management and approves 
bandwidth requests on garekeeper-routed calls while direct cans ear, be made withrn 
the network without informing the gatekeeper about the bandwidth usage. In the case 
where direct calls ate used within the IP telephony network, service diffetenuattorr, re. 

m echanisms an network Cements mat prioritise and forward important calls before 

,ess important caUs, is necessary as soon as some sort of guarantees for a service . 

requited. Garekeeper approved calls can then be marked as important and forwarded 

Erst while direct calls are marked as less important. 

For ongoing calls, problems might occur if there are additional e^poum that warat ,o 
join the session and these endpoinrs are located on networks segtnems without 
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available resources or where die available resources are not sufficient to provide 
predictable service. This issue will only occur when there is a multipart conference 
involving more than two endpoints. 

5 Yet another problem is that different H.323 zones might be separated by non-H.323 
enabled networks. Currendy there are no means to provide a predictable sendee in diis 
case because resources are not controlled in a non-H.323 network. 

QoS support for H.323 using RSVP is currendy under development. However, QoS 
10 support using RSVP is not scalable, especially not when there are calls made between 
endpoints in different zones where there are a non-H.323 enabled network in 
between. RSVP does per call signalling and reservations that would load the networks 
with signalling instead of useful traffic, i.e. media streams, and set-oap per call state in 
routers. 

15 

Current H.323 systems do not allow reservations in advance, which makes it hard to 
plan meetings with predicted quality. 

Yet another problem in the H.323 standard is that a bandwidth, request is always 
20 approved or rejected. A more flexible approach between the bandwidth management 
functionality and the end-user is preferred. 

The European patent document EP 0942560 discloses an apparatus and method for 
25 speech transport with adaptive packet size. It aims to minimize end-to-end delays 
caused by network traffic and low capacity routers in the network topology between 
two IP telephony devises. The aim is achieved by adopting packet sizes for speech 
transport However, the document do not address how admission control can be done 
in speech transport systems, i.e. evaluating if there are sufficient capacity in the 



OCID: <WO 0221797A1J_> 



10 



15 



XVO ,,2/21797 PCT/SE01/0.876 



7 

network before starting sessions and for communicating admission decisions to the 
svstem. 



SUMMARY OF THE INVENTION 

The object of the present invention is to provide a way of handling recourse 
management issues and admission control within an IP telephony system. 

The above-mentioned object is achieved by a method, a resource manager and a 
system according to the characterising part of die independent claims. 

Thanks to that the topology aware resource manager provided by the present 
invention, comprises means for collecting routing information concerning the IP 
network, means for obtaining resource information concerning resources within the 
IP network, means for creating a resource map by means of combing said routing 
information and resource information, and means for interacting with the gatekeeper 
it is possible for the resource manager to perform recourse management issues and 
admission control within the system. 



20 



The method provided by the present invention comprising the steps of: 

- collecting routing information concerning the IP network; 

- obtaining resource information concerning resources within the IP network; 

- creating a resource map by means of combing said routing information and resource 
2 5 information; 

makes it possible to perform recourse management issues and admission control 
within die system, by means of said resource map and by interacting with a gatekeeper. 



Preferred embodiments are set force in the dependent claims. 



30 
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An advantage of the present invention is that increased utilisation of the network that 
will be achieved. 

Another advantage of the present invention is that it is be possible to prioritise certain 
5 traffic and still allow other traffic in the same network. This gives flexible system 
solutions. 

Another advantage of the present invention is that it makes it possible to reserve 
resources in advance to allow planned meetings and events. 

10 

Yet another advantage of the present invention is that it makes it possible to allow 
calls with predictable quality through non-H.323 domains if these domains where QoS 
enabled with inter-domain communicative resource managers. It would be In these 
inter-zones segments resources can be reserved in advance for traffic aggregates to 
1 5 avoid per call signalling in these segments, i.e. trunk bandwidth. This is a very resoxirce 
efficient feature of the described technology. Reservations in advance are allowed to 
vary over time, e.g. reserve more bandwidth during working hours and less otherwise. 
In other words, the user of the described technology can schedule resources by 
predicting the resource need over time. 

20 

A further advantage of the present invention is the flexible interaction between service 
provider and end-user that a full resource map can provide if this is customer need. 

2 5 BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1-3 are related to the state of the art and are described above. 

Figure 1 shows an overview of the major components in an H.323 system according 
30 to the state of the art. 
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Figure 2 is a diagram depicting multipoint communication according to the state of 
the art. 

Figure 3 is a block diagram illustrating a topology for an H.323 enabled network 
according to the state of the art. 
5 Figure 4 is a block diagram illustrating an exemplary topology aware resource 
manager entity RM within an IP telephony system, according to a first embodiment of 
the present invention. 

Figure 5 is a block diagram illustrating an exemplary topology aware resource 
manager entity RM within an IP telephony system 500, according to a second 
10 embodiment of the present invention. 



DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

15 Figure 4 is a block diagram illustrating an exemplary topology aware resource 
manager entity RM within an IP telephony system 400, according to a first 
embodiment of the present invention. The resource manager RM comprises topology 
aware resource manager functionality. It is comprised in an IP telephony system e.g. 
an H323 system. Such a system is described Figure 1, above under "background of the 

2 0 invention". Hence, in addition to the resource manager RM, the IP telephony system 
typically comprises IP telephony components such as one or many gatekeepers Gk, 
gateways G, and terminals, as well as IP network elements such as routers R, edge 
routers ER and Local Area Network (LAN) segments to which the terminals typically 
are connectable. The IP telephony system (400) is used to enables end-users to use an 

25 IP network as the transmission medium for multimedia. 

The resource manager RM interacts with the gatekeeper Gk and handles all resource 
management issues for initiated and ongoing calls and admission control for call set- 
up requests. The interaction between the RM and the Gk can be implemented in a 
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number of ways, e.g. via a communication protocol, inter process communication, 
functional calls between integrated software modules, etc. 

Topology awareness is the availability of correct routing and resource information, 
L- which is essential to a system which performs resource management and admission 
control. The resource manager RM retrieves routing information concerning the IP 
network, i.e. the topology of the IP network. 

In the case wherein die IP network is routed using link-state routing protocol, the 
resource manager RM participates in the routing and acts as a router, i.e. the RM peers 

10 with other routers, without advertising any routes of its own, to retrieve routing 
information of the IP network. The basic principle on which link-state protocols are 
built ensures diat all routers have the complete routing information. When 
participating in the routing protocol, the resources manager RM receives the routing 
information as fast as any odier router in die routing domain and can therefore detect 

1 5 changes in the topology instandy. 

In the case wherein the IP network is routed using a distance vector protocol, or 
static routing, the metiiod of peering cannot be used. In this case, the routing 
information is retrieved by measurements such as trace route (See Kessler G., A Primer 
on Internet and TCP/IP Tools, IETF, KFC1739) and/or die use of Simple Network 

20 Management Protocol (SNMP) auto discovery (see Keshav et Al, Discovering frtternet 
Topology, 

http:l I iimnv.cs.cornelLedul skesbav I papers! discoveiy.pdf * July 1998). SNMP is a set of 
protocols for managing complex networks. When the resource manager RM has 
retrieved the routing information, it uses a network management: protocol, such as 
25 SNMP (see Case etAl, Introduction to Version 3 of the hiternet-standards JSfetmrk Manage??ient 
Fraweivork, IETF, KFC2570\ to collect information on the routers and their interfaces 
(e.g. the interface type and speeds). The information is used by the RM to complement 
the gained routing information and make sure that it has an accurate routing topology. 
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The resource manager RM combines the routing information and resource 
information it gets from call set-up requests from the Gk to create a resource map. 
The resource map contains information of how much resources (eg. bandwidth) that 
are available and reserved over time on a per link basis. The resource manager RM 
5 uses the resource map to assist the gatekeeper Gk in the decision whether there are 
resources available or not, for a call that someone is initiating. 

In the case of gatekeeper-routed calls, the gatekeeper Gk is responsible for 
approving or rejecting initiated calls from terminals. The gatekeeper Gk interacts xvith 
the resource manager RM and asks the resource manager RM if there will be enough 
10 resources through the routed path between the source endpoint and the destination 
endpoint of an initiated call, to give the predictable quality. The resource manger RM 
answers the question by evaluating what network path the call will use and for each 
link along that path it calculates if there are sufficient resources to admit the call, i.e. 
the resource manager RM performs path-sensitive admission control on the resource 
15 request. The admission control is performed based on the information in the resource 
map. This will solve the above-mentioned problem addressed as the changes in user 
behaviour. No heuristic model can cope with changes in user behaviour, but the 
topology aware resource manager RM does that by being up to date about the 
resource utilisation. The same goes for the problem with denial of service. 

Another problem addressed above is the changes in topology. The resource manager 
RM monitors on-going calls in the IP telephony system and recalculates the resource 
usage per Hnk whenever any change occurs i.e. updates the resource map. If the 
updated resource map show that resources are too limited to be able to fulfil all on- 
25 going calls the resource manager RM will report this to the to the gatekeeper Gk. If 
the resources are limited as just described, it is possible to let either the resource 
manager RM or the gatekeeper Gk prioritise which calls that should be kept and which 
to terminate. By performing this prioritisation, degraded quality for everyone involved 
is avoided. This prioritisation also makes the number of lost calls rrtininused. Another 



20 
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way to prioritise services whenever topology changes occur is to let video streams gets 
lower priority compared to the voice sendee. 

Figure 5 is a block diagram illustrating an exemplary topology aware resource 
5 manager entity RM within an IP telephony system 500, according to a second 
embodiment of the present invention. In this second embodiment, the resource 
manager RM is used in a multipart conferencing scenario involving more dian two 
endpoints. Within a multipart conferencing there will always be a multipoint controller 
MC involved in the communication. The IP telephony system shown in Figure 5 is the 

1 0 same typically IP telephony system as the one in illustrated in Figure 4 except for that 
it additionally comprises a multi-point controller MC. The system may comprise more 
than one multi-point controller. The multi-point controller MC has knowledge about 
which endpoints that participates in the multipart conference and the MC will also 
control diese endpoints. The resource manager RM provides the admission control to 

15 the multi-point controller MC, either direcdy or indirectiy via the gatekeeper Gk, in 
the same way as provided to the Gk as describe above. The resource request may in 
this case contain more than two endpoints. 

In a multipart conferencing call, a task to add participants as resource efficiently as 
20 possible arises. In this case, the resource manager RM recommends the multi-point 
controller MC, by means of the resource map, which distribution method 
(centralised/decentralised or an appropriate hybrid between these) to use to make it 
possible for the added part to join the session in a resource efficient manner. The 
distribution method to use is depending on die resource map and hence, only the 
2 5 resource manager RM has the possibility to answer this. 

In case diere are no resources available with predictable quality, different methods to 
handle this exists. The user can get service without priority or the user can be rejected 
to participate in the conference due to lack of resources. 
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In case different priorities are used, there must be either two multicast sessions of 
which one is prioritised and the other is not, or a separate unicast session to the part 
that suffers from lack of resources. 

-In the multicast case, the part with less predictable resources must listen to the 
session without priorities and the traffic will therefore never be distributed to that 
part of die network. 

-In the unicast case, one part of the session can relay its traffic as unicast without 
priority to the part with lack of predictable resources. 

For both the unicast case and the multicast case, the bandwidth request is approved or 
rejected. From an end-user point of view it is more convenient to have a reject with 
conditions, which is possible when using the resource manager RM according to the 
present invention. 

For instance, the end-user requests for 64 kbit/s voice service and 128 kbit/s video 
service. The available resources are not sufficient to fulfil this request but only 128 
kbit/s is available which is found out by the resource manager RM by means of the 
resource map. The answer from die resource manager RM could then be e.g. "Your 
request cannot be fulfilled, only 128 kbit/s can be reserved for you. Please respond to 
this message within 5 minutes to reserve these 128 kbit/s." A preliminary booking of 
resources is made by the resource manager RM, based on the original request from the 
gatekeeper Gk or multi-point controller MC This preliminary booking request is then 
cancelled unless there is a response to the message sent from the resource manager 
RM to the gatekeeper Gk or MC. For the end-user, it is then possible to select which 
service to prioritise in favour of the other. I.e. diat is in case there is a wish to put 
either of the services in favour of the other. The same goes if only one service is 
considered. The user wants e.g. to run high-quality voice, but due to lack of resources 
he accepts medium-quaHty voice with predictable quality rather than high-quality voice 
without possibilities to predict the quality. 
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Even though the state of the art describes H.323 and the solution according to the 
present invention is adapted to that recommendation other similar IP telephony 
solutions are possible, e.g. there exists a competing IP telephony solution according to 
the IETF standard SIP where the same solutions are applicable. 

The resource manager RM comprises means for performing the method steps 
described above. 

The resource manager functionality is implemented by means of a computer program 
product comprising the software code means for performing functionality. The 
computer program is run on a standalone server interacting with gatekeepers, or is run 
on the same hardware as the gatekeeper functionality. It can be integrated with 
software that implements gatekeeper functionality, it may also run on routers or other 
network entities. The resource manager functionality may also be distributed to run on 
multiple nodes and/or distributed geographically over a network. The above is also 
applicable for interaction with other entities performing the same functionality as 
gatekeepers. The computer program is loaded directly or from a computer usable 
medium, such as a floppy disc, a CD, the Internet etc 

The present invention is not limited to the above-described preferred embodiments. 
Various alternatives, modifications and equivalents may be used. Therefore, the above 
embodiments should not be taken as limiting the scope of the invention, which is 
defined by the appending claims. 
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CLAIMS 



1. A topology aware resource manager (RM) within an Internet Protocol IP 
5 telephony system (400) for transmission of multimedia over an IP network, the 

system comprising a gatekeeper (Gk), 

characterised in that the resource manager (RM) comprises: 
means for collecting routing information concerning the IP network; 
means for obtaining resource information concerning resources within the IP 
1 o network; 

means for creating a resource map by means of combing said routing information 

and resource information; 
means for performing recourse management issues and admission control within 
the system (400) by means of said resource map and by interacting with the 
15 gatekeeper (Gk). 

2. The resource manager (RM) according to claim 2, wherein it comprises means for 
obtaining resource information from call set-up requests from the gatekeeper (Gk). 



20 



30 



3. The resource manager (RM) according to any of die previous claims 1-2, wherein 
the IP system is routed using link-state routing protocol, the resoutce manager 
(RM) comprises means for participating in the routing and acting as a router within 
the system (400) without advertising any routes of its own, to retrieve routing 
information of the IP network. 

4. The resource manager (RM) according to any of the previous claims 1-2, wherein 
the IP network is routed using a distance vector protocol, or static routing, the 
resource manager (RM) comprises means for using measurements such as trace 
route and/or the Simple Network Management Protocol (SNMP) auto discovery 
to retrieve routing information of the IP network. 
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5. The resource manager (RM) according to any of the previous claims 1-4, wherein it 
comprises means for using the resource map for evaluating what network path an 
initiated call between a source endpoint and a destination endpoint within the 
system (400) will use 

6. The resource manager (RM) according to claim 5, wherein it comprises means for, 
calculating, for each link along that path, if there are sufficient resources to admit 
the call. 

7. The resource manager (RM) according to claim 6 3 wherein said calculation is 
reported to the gatekeeper (Gk). 



8. The resource manager (RM) according to any of the previous claims 1-7, wherein it 
1 5 comprises means for updating the resource map by monitoring on-going calls in 

the IP telephony system and recalculating the resource usage per link whenever 
any change occurs within the system (400). 

9. The resource manager (RM) according to claim 8, wherein the resource map shows 
20 that the resources are too limited to be able to fulfil all on-going calls, the recourse 

manager (RM) comprises means for prioritising which calls that should be kept 
and which to terminate. 

10. The resource manager (RM) according to claim 8, wherein the resource map shows 
25 that the resources are too limited to be able to fulfil all on-going calls, the recourse 

manager (RM) comprises means for reporting this to the gatekeeper (Gk), making 
it possible for the gatekeeper (Gk) to prioritise which calls that should be kept and 
which to terminate. 
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11. The resource manager (RM) according to any of the previous claims 1-10, wherein 
it is used in a multi part conference scenario involving more than two end-points 
within the system (500) which system further comprises a multi-point controller 
(MC), the resource manager (RM) comprising means for interacting with the multi- 
point controller (MC) for performing said recourse management issues and 
admission control. 

12. The resource manager (RM) according to claim 11, wherein said interaction with 
the multi-point controller (MC) is performed via the gatekeeper (Gk). 

13. The resource manager (RM) according to any of die claims 11-12, wherein 
recourses are available, but not enough to fulfil the amount of recourses requested 
in a call initiation, the resource manager (RM) comprises means to reject the call 
with conditions, i.e. by offering said available recourses to the initiator of the call. 

14. An Internet Protocol (IP) telephony system comprising a gatekeeper (Gk), one or 
more routers (R) and multiple a plurality of end-points characterised in that the 
system further comprises a topology aware resource manager (RM) according to 
any of the claims 1-13. 



20 



15. A method for handling performing recourse management issues and admission 
control within an Internet Protocol IP telephony system (400) adapted for 
transmission of multimedia over an IP network, the system (400) comprising a 
topology aware resource manager (RM); 

characterised in that the method comprises the following steps to be performed 
by the resource manager (RM): 

- collecting routing information concerning the IP network; 

- obtaining resource information concerning resources within the IP network; 

- mating a resource map by means of combing said routing information and 
30 resource information; 



25 
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- performing recourse management issues and admission control within the system 
(400) by means of said resource map and by interacting with a gatekeeper (Gk), 

16. The method according to claim 15, comprising the further step of 

5 - the resource manager (RM) obtaining resource information from call set-up 

requests from the gatekeeper (Gk). 

17. The method according to any of the claims 15-16, wherein the IP system is routed 
using link-state routing protocol, the metiiod comprising the further step of: 

10 - the resource manager (RM) participating in the routing and acting as a router 

within the system (400) without advertising any rotes of its own, to retrieve 
routing information of the IP network. 

18. The method according to any of the claims 15-16, wherein the IP network is 
1 5 routed using a distance vector protocol, the method comprising the further step of: 

- the resource manager (RM) using measurements such as trace route and/or the 
Simple Network Management Protocol (SNMP) auto discovery to retrieve routing 
information of the IP network. 

2 0 19. The method according to any of the claims 15-18, comprising the further step of: 

- using the resource map for evaluating what network path an initiated call between 
a source endpoint and a destination endpoint within the system (400) will use 

20. The method according to any of the claims 15-19, comprising the further step of: 

2 5 - calcuhtijigp for each link along that path, if there are sufficient resources to admit 

the call. 

21. The method according to claim 20, comprising the further step of: 

- reporting said calculation to the gatekeeper (Gk). 

30 
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22. The method according to any of the claims 1 5-21, comprising the further step of: 

die resource manager (RM) updating the resource map by monitoring on-going 
calls in the IP telephony system and recalculating the resource usage per link 
whenever any change occurs within the system (400). 

23. The method according to claim 22, wherein the resource map shows that the 
resources are too limited to be able to fulfil all on-going caUs, the method 
comprising the further step of: 

- the resource manager (RM) prioritising which calls that should be kept and which 
1 o to terminate. 

24. The method according to claim 22, wherein die resource map shows that the 
resources are too limited to be able to fulfil all on-going calls, the method 
comprising the further step of: 

15 - the resource manager (RM) reporting this to the gatekeeper (Gk), making it 

possible for the gatekeeper (Gk) to prioritise which calls that should be kept and 
which to terminate. 

25. The method according to any of the claims 15-24, wherein it is used in a multi part 
20 conference scenario involving more than two end-points within the system (500), 

which system further comprises a multi-point controller (IVtC), the method 
comprising the further step of: 

- the resource manager (RM) interacting with the multi-point controller (MC) for 
performing said recourse management issues and admission control. 



25 



26. The method according to claim 25, wherein said interaction with the multi-point 
controller (MC) is performed via the gatekeeper (Gk). 
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27. The method according to any of the claims 25-26, wherein recourses are available, 
but not enough to fulfil the amount of recourses requested in a call initiation.,, the 
method comprising the further step of: 

- the resource manager (RM) rejecting the call with conditions, i.e. by offering said 
5 available recourses to the initiator of the call. 

28. A computer program product direcdy loadable into the internal memory of a 
processing means widiin a topology aware resource manager (RM) and/ or a 
gatekeeper (Gk) within a IP telephony system (400) system, comprising the 

10 software code means for performing the steps of any claims 15-27. 

29. A computer program product stored on a computer usable medium, 
comprising readable program for causing a processing means in topology 
aware resource manager (RM) and/ or a gatekeeper (Gk) within a IP telephony 

15 system (400) system, to control an execution of the steps of any of the claims 

15-27. 
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